Large communications networks, such as subscriber-based access networks, connect many end-users (i.e., from hundreds of thousands to millions) to the Internet through various intermediate network nodes. FIG. 1 depicts an example of a subscriber-based network 100 in which end-users are connected to the Internet 102 through a combination of customer premises equipment (CPE) 104, intermediate network nodes 106, and a metropolitan area network (MAN) 108. The MAN includes a series of service provider edge devices 110 that are connected in a ring around the metropolitan area. The CPE for each end-user provides the interface between various end-user devices, such as computers, telephones, and televisions and the intermediate network nodes. The CPE may include a modem, such as a cable modem, a digital subscriber line (DSL) modem, or a dial-up modem. The intermediate network nodes provide aggregation and traffic management functions between the CPE and the service provider edge devices. The service provider edge devices provide further aggregation and traffic management functions on the traffic that is received from the intermediate network nodes.
In order to provide the end-users with an acceptable level of service within a given domain and with bounded resources when accessing the Internet 102, it is important to be able to control the traffic flow to and from the end-users at different points within the network. One technique for controlling the flow of traffic in the network is to assign static bandwidth limits to each end-user. For example, each end-user can be assigned a certain specified bandwidth limit, which cannot be exceeded at any time. By controlling the bandwidth of each end-user such that each end-user is guaranteed a minimum service level, a network manager can design a network for known peak traffic conditions. Although assigning static bandwidth limits to each end-user works well to control the flow of traffic in a network and to guarantee minimum service levels, the static bandwidth limits do not take into consideration the fact that different traffic types have different bandwidth needs. That is, some traffic, such as voice traffic, may be delay sensitive and require relatively small amounts of bandwidth while other traffic, such as large file downloads, may not be degraded by delay but may require relatively large amounts of bandwidth. In addition, assigning static bandwidth limits to guarantee minimum service levels can cause bandwidth demand of some users to go unsatisfied because bandwidth resources are being reserved to ensure the guaranteed minimum service levels to other end-users.
One technique for controlling the flow of traffic to meet specified bandwidth needs for different types of traffic is known as Differentiated Services (Diffserv). An example of a DiffServ architecture is described in the document entitled, “An Architecture for Differentiated Services,” (IETF Request for Comment (RFC) 2475, December 1998). Referring to FIG. 2, the DiffServ architecture 214 described in RFC 2475 includes a classifier 216 and a traffic conditioner module 218, with the traffic conditioner module including a meter 220, a marker 222, and a shaper/dropper 224. The classifier identifies packets based on the content of packet headers according to defined classification rules. The meter measures the temporal properties (i.e., rate) of traffic streams that are identified by the classifier and the results of the measuring are used to affect the operation of the marker or the shaper/dropper. The marker sets the DiffServ codepoint in a packet header based on defined rules and the shaper/dropper can delay packets within a traffic stream to cause the stream to conform to a defined traffic profile or discard packets that are found to be outside of a defined traffic profile. As depicted in FIG. 2, the marker and shaper/dropper operate in response to information from the meter and the meter operates in response to information from the classifier.
In a large subscriber network, such as the subscriber-based access network described with reference to FIG. 1, DiffServ functions are often installed in the intermediate network nodes 106. For example, the intermediate network nodes include classifiers 116 and traffic conditioner modules 118, as depicted in FIG. 1, for controlling the flow of traffic at the outputs of the intermediate network nodes. In order to control the flow of traffic at the outputs of the intermediate network nodes, classification rules that identify criteria for classifying incoming traffic and conditioner rules that control the flow rate of the classified traffic are set. Typically, the classification and conditioning rules are installed with the same static settings throughout the network at the time that the DiffServ features are initiated. Although this “set and forget” approach may work well for controlling the flow of traffic at the time that the DiffServ features are initiated, traffic patterns of end-users tend to change over time. For example, new applications that were previously unknown to the network manager may become popular after the classification and conditioning rules are installed.
Changes in the traffic patterns of end-users may cause the performance (i.e., as measured by overall throughput) of the network to degrade. Performance degradation may result because conditioning rules are not appropriate for the new traffic patterns. While the conditioning rules in a large subscriber-based network are typically static, there are known techniques for dynamically adjusting the conditioning rules to account for changes in traffic patterns. Although dynamically adjusting conditioning rules is possible, traffic conditioners act on the traffic as it is classified. In known subscriber-based DiffServ networks, the “set and forget” nature of the classifiers does not provide a mechanism to enable the classification rules to be adapted to the changing nature of the traffic. If the static classification rules do not adequately classify the new traffic patterns, then the effectiveness of dynamically adjusting conditioning rules to account for changes in traffic patterns is limited. For example, if a new application is included in a traffic class with other applications, it is impossible to individually control the new application with a conditioning rule that is specific to the new application unless the new application can be individually identified. In addition, trying to control the new application that is included in a traffic class with other known applications without individually classifying the application may have adverse implications on the other known applications.
As described above, the task of adapting classification and conditioning rules for a single DiffServ instance can be cumbersome. In a subscriber-based network with hundreds of thousands to millions of end-users, the task of adapting DiffServ instances is enormous. One example of a DiffServ architecture that can be adapted to a large network is described in the published International patent application entitled “Communication Network Method and Apparatus,” (WO 00/72516 A1, published 30 Nov. 1998). The patent application discloses a centralized network system for setting and distributing conditioning rules among multiple DiffServ instances. Although the centralized setting and distributing of conditioning rules works well, as indicated above, the effectiveness of adapting conditioning rules depends on the classification of the traffic. The effectiveness of adapting conditioning rules degrades as traffic patterns change if the classification rules are not adapted to the changing traffic patterns.
In view of the need to control the flow of traffic in networks, such as large scale subscriber-based networks, and in view of the changing nature of end-user traffic patterns, what is needed is a technique for adapting the classification of network traffic to account for changing traffic patterns that can be implemented in a DiffServ environment and that can be scaled for use in a large subscriber-based network.